The principal benefit of corporate networks today is in interconnecting a multitude of network resources to provide the backbone for various means of communication within and outside the corporation. Today's networks span multiple locations, geographic regions, continents, and time zones, and interconnect thousands of devices. Due to the sheer number of devices present on the network, the networks are very dynamic—devices are added, moved, and removed from the network to address the current needs of the corporation. When the networks are laid out initially, the distribution of various network devices is well-known. However, over time, due to the dynamic nature of corporate networks, knowledge regarding the location of various network devices erodes. At that time, the need arises to “walk” the network and “re-discover” components attached to it together with their location and interconnection information, which allows for restoring network topology and provides information for network analysis and optimization.
At the same time, the majority of corporate technical assets are deployed on corporate networks. As these assets are allocated and reallocated to different areas, groups, and individuals, it becomes very difficult to keep proper track of these allocations for financial accounting purposes. Timely and accurate information regarding deployment of various network assets is crucial for accurate accounting and asset tracking functions. These asset tracking needs are exacerbated in the case of a disaster. If a disaster results in loss of network assets, information regarding the most recent (ultimately—for the moment of the disaster) allocation of these assets becomes crucial for controlling the damage. Timely network discovery and storage of discovered information in appropriate historical databases addresses these issues.
As technological innovations bring new features (like serial numbers burned into central processing units (CPUs), printers, and monitors) into existing devices as well as completely new types of devices (such as internet protocol (IP)-based telephones), network discovery needs may change. Instead of simply identifying a device on the network, there may be an interest in collecting some additional, presently-unforeseen information about the discovered device. This ever-changing environment requires flexible, easily-reconfigurable and easily-adaptable discovery solutions.
Typically, network discovery is implemented as various forms of exhaustive network sweeps. There are some other approaches based upon querying some auxiliary databases (Doman Name System (DNS), Windows Internet Naming Service (WINS), Dynamic Host Configuration Protocol (DHCP), etc.) to get network addresses of registered devices. However, all these approaches rely on the devices registering themselves in one of those auxiliary databases, which may not occur for all of the devices. Thus, the most authoritative and reliable way for implementing network discovery remains the complete network sweep.
In connection with a complete network sweep, every address in the address space of the network is “touched” to verify the presence or absence of a device at that address. If a device is found at some network address, further queries are directed to this address to collect the required level of information for proper identification of the discovered asset. For the ease of management, networks are typically designed as sparse, such that the address space on the network is typically 10 to 100 times the number of devices actually connected to the network. Thus, to discover thousands of devices on a network, a discovery mechanism typically must touch hundreds of thousands of potential addresses.
This problem is further exacerbated by the nature of the Transmission Control Protocol/Internet Protocol (TCP-IP) protocol ubiquitous on today's networks. According to the transport level specification of the TCP-IP protocol, a communication between two points on the network is considered failed if an expected response was not received within a certain timeout period. Due to the random nature of signal propagation on TCP-IP networks, the timeout value is typically much larger then the average round-trip time for a message. Thus, to verify an absence of a device on a particular address in the address space of the network, a discovery agent should send a request and then wait until the expiration of the timeout interval. To improve the reliability of this process in case of a timeout, a discovery agent typically repeats the request 2-3 times, thereby further slowing the discovery process.
Similarly, when a device is discovered on the network, a discovery agent must try various protocols (like Simple Network Management Protocol (SNMP) with different community names, Hypertext Transfer Protocol (HTTP) on different ports, etc.) as the agent does not know ahead of time the nature of the discovered device and on what protocol with which parameters the device will reply. Again, to confirm the failure of a particular protocol, a discovery agent has to wait throughout the timeout interval and then repeat its attempt several times.
Due to the aforementioned problems, typical network discovery solutions are very slow. Existing network management software products (such as HP OPENVIEW, etc.) would take several days or even weeks to perform an exhaustive sweep of the network. Due to the dynamic nature of networks, discovery data achieved through these processes will be outdated by the time it is collected.